A wireless communication system performs a verification and authentication procedure on a terminal in order to provide a service safely. Such an authentication function for a terminal emerges as a basic requirement necessary for stability of a service and stability of a network.
For example, the Institute of Electrical and Electronics Engineers (IEEE) 802.16-based wireless communication system recommends a new Privacy Key Management version 2 (PKMv2) in order to provide stronger authentication framework. The PKMv2 supports a Rivest Shamir Adleman (RSA)-based authentication scheme for mutually authenticating a terminal and a base station, and an Extensible Authentication Protocol (EAP)-based authentication scheme for performing authentication of a terminal through an upper authentication protocol. The PKMv2 performs authentication of a terminal, a base station, and a user through various combinations of these authentication schemes.
In addition, after mutual authentication between a terminal and a base station is completed in the IEEE 802.16-based wireless communication system, a Message Authentication Code (MAC) is used for authentication of a control message exchanged between the terminal and the base station. After a Traffic Encryption Key (TEK) is generated, a MAC Protocol Data Unit (MPDU) is encrypted in an AES-CCM mode using the TEK. When a message is generated at a base station or a terminal, the MAC is added at the base station and decrypted at the terminal, or added at the terminal and decrypted at the base station in order to verify that the message is not changed by a different base station or terminal.
FIG. 1 illustrates a format in which a MAC is added to a control message according to the principles of the present disclosure. For the MAC, a Cipher based Message Authentication Code (CMAC) and a Keyed-Hash Message Authentication Code (HMAC) are used. A situation in which the CMAC is generated and added to a control message is described.
Referring to FIG. 1, when a control message is generated, a base station or a terminal generates a CMAC 110, adds it to the last portion of the control message 100, and transmits the control message 100 to which the CMAC 110 has been added to a terminal or a base station. When receiving the control message 100 including the CMAC 110, a terminal or a base station in a reception side generates a CMAC in the same way as the base station or terminal in the transmission side and performs an integrity check of the control message by comparing the generated CMAC with the CMAC of the received control message. The CMAC is generated based on Equation (1).CMAC:=Truncate(AES-MAC(CMAC_KEY_*,AKID|CMAC_PN_*|STID|FID|24-bit zero padding|MAC_Control_Message),64)CMAC_KEY_U|CMAC_KEY_D=Dot 16 KDF(CMAC-TEK prekey, “CMAC KEYS”, 256)AKID=Dot16KDF(AK, 0b0000|PMK SN|AMSID* or MS MAC address|BSID|“AKID”, 64)CMAC-TEK prekey=Dot16KDF (AK, AK_COUNT|“CMAC-TEK prekey”, 160)AMSID*=Dot16KDF(MS MAC address|80-bit zero padding, NONCE_AMS, 48)  (1) [Eqn. 1]
The CMAC is generated by selecting the lower 64 bits (=8 bytes) of 128 bits, which are result values of AES-CMAC (refer to Internet Engineering Task Force Request for Comment (IETF RFC) 4493) according to Equation (1).
Here, CMAC_KEY_* is the CMAC_KEY for Uplink/Downlink generated from an Authentication Key (AK), CMAC_PN_* is a value that increases by 1 whenever a control message is transmitted and is a packet number counter value for Uplink/Downlink. STID is an identifier allocated to a relevant terminal, BSID is an identifier of a relevant base station, FID (Flow ID) is an identifier allocated to connection of a relevant terminal, MAC_Control_Message is control message contents to be transmitted, and NONCE_AMS is a random number generated by an AMS during network entry. Though CMAC generation has been exemplarily described for message authentication in FIG. 1, HMAC may be used as a control message.
FIG. 2 illustrates a format in which an integrity check value is added to MPDU according to the principles of the present disclosure.
Referring to FIG. 2, when an MPDU including a MAC header 200 and a plaintext payload 210 is generated, the L-byte plaintext payload 210 is encrypted based on an AES-CCM scheme, a Packet Number (PN) 202 is added to a front portion of the encrypted plaintext payload 211, and a 8-byte Integrity Check Value (ICV) is added to a rear portion of the encrypted plaintext payload 211, such that an encrypted MPDU is formed. Consequently, the encrypted MPDU includes the MAC header 200, the PN 202, the encrypted plaintext payload 211, and an Integrity Check Value 220. Therefore, when receiving the encrypted MPDU, a reception side decodes the encrypted MPDU and determines whether the ICV 220 is valid to check the integrity of the MPDU.
The 8-byte ICV 220 is generated according to an AES-CCM scheme using a Traffic Encryption Key (TEK), a MAC header, a PN, and a plaintext payload as inputs.
As described above, for integrity check of a control message and an MPDU, an overhead of 8 bytes (that is, 64 bits) is added. The overhead increases in proportion to the number of control messages or the number of MPDUs. This may act as a factor that deteriorates system performance.
Therefore, there is a need for an alternative for reducing the size of an authentication overhead for a control message and an MPDU in a wireless communication system.